1. Technical Field
This invention generally relates to the data processing field. More specifically, this invention relates to the location of object creation in object oriented systems.
2. Background Art
Since the dawn of the computer age, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object oriented programming concepts. The goal of using object oriented programming is to create small, reusable sections of program code known as xe2x80x9cobjectsxe2x80x9d that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
The Java programming language developed by Sun Microsystems is one modem object oriented programming language that has become very popular in recent years. From a programmer""s point of view, one of the advantages of the Java programming language is that memory allocation and reclamation are handled entirely by the run-time system, which relieves the programmer of the burden of determining how and when to destroy unneeded objects. All objects (other than those of primitive types) are allocated from a common xe2x80x9cheapxe2x80x9d, or section of memory. The garbage collection mechanism then monitors the objects in the heap, and periodically deletes unneeded objects, thereby reclaiming portions of the heap that are occupied by objects that can no longer be accessed from the user""s program.
One problem with the Java automatic allocation and reclamation of memory is that users have less control over their program""s performance. Each time an object is allocated, a certain cost is incurred as the memory manager updates its data structures. Furthermore, an additional cost must be paid to reclaim the object during garbage collection. Although these costs are small when considered individually, the sheer frequency of object allocation and reclamation result in a significant portion of program execution time being spend in the memory manager, allocating and reclaiming memory for objects.
Java""s memory management overhead is far greater than that of the C++ programming language, primarily because every Java object is allocated from the heap. In C++, programmers are given more control over the allocation of their objects. In particular, C++ programmers are able to declare objects to be local to a method. These objects come into existence when the method is invoked, and are automatically reclaimed when the method invocation terminates. Further, the run-time cost of allocating these objects is essentially zero, since they simply occupy space in the method""s invocation stack frame. Adding an object to the invocation stack frame simply means that the amount by which the stack pointer is moved must increase, but no additional instructions are required to do this. Compare this with Java, where every created object, no matter how small or how temporary, requires overhead from the run-time memory manager.
Recently, researchers in compiler technology have been working on ways to allocate some Java objects on a method""s stack frame, rather than going to the heap for each and every object, thereby improving on the performance of the native Java capabilities. In particular, if a compiler can automatically detect Java objects whose xe2x80x9clifetimesxe2x80x9d do not extend beyond the method in which they are created, these objects can be automatically allocated on the stack by the compiler rather than from the garbage-collected heap, resulting in improved performance. The technology used to determine which objects may be allocated on the stack is called xe2x80x9cescape analysisxe2x80x9d. The idea is to determine which objects have lifetimes that do not xe2x80x9cescapexe2x80x9d from the methods that create them. Escape analysis is presented in a paper by Choi et al., xe2x80x9cEscape Analysis for Javaxe2x80x9d, in Proceedings of the Conference on Object Oriented Programming, Systems, and Languages (OOPSLA), Denver, Colo. (November 1999), p. 1-19.
Escape analysis as described by Choi et al. is limited to allocating objects on a method""s stack if their lifetimes do not escape from their creating method. However, there are a large class of Java objects which do escape from their creating method, and yet could be allocated on the stack if properly identified and managed. Without an apparatus and methods for allocating a greater number of Java objects to a method""s call stack, the computer industry will continue to suffer undue performance limitations caused by allocating Java objects from the heap that could be allocated on a method""s stack.
According to the preferred embodiments, an object oriented mechanism and method allow allocating a greater number of Java objects on a method""s invocation stack. Each instruction that creates an object (i.e., allocation instruction) is first analyzed to determine whether it is one of the following three types: no escape, global escape, and arg escape. If an allocation instruction is global escape, the object must be allocated from the heap. If an allocation instruction is no escape, it can be allocated on the method""s stack. If an allocation instruction is arg escape, further analysis is required to determine whether the object can be allocated on an invoking method""s stack or must be allocated from the heap. If the method that contains an arg escape allocation instruction can be inlined into a method from which the lifetime of the object does not escape, the object can be allocated on the invoking method""s stack. This inlining can be done for several layers up, if needed and possible. This allows for nested objects to be potentially allocated on a method""s stack, instead of forcing each of these objects to be allocated from the heap.